IBM Engineering Lifecycle Management

IBM Engineering Requirements Management DOORS former IBM Rational DOORS profits very much from the mighty market position it had till today. It had been the most favored requirement engineering tools suite with the highest investments in the infrastructure concerning hardware, software, and knowledge sources. It was embedded in knowledge sources of test stands, hardware labs, and knowledge database servers. It allowed for some of the highest profit changes and made the fame with it. But the paradigms of requirements engineering change. If not were superseded by completely different approaches for the target solution worlds. The foremost position in the selling tables is unstable if changes are not solved or coped with by the strategist at IBM and their customers. Since the highly successful alternative suits are already at the market, and some are from IBM already the lifecycle for IBM Engineering Requirements Management DOORS is at the later highs. But the suite is still at the very top and very popular. There are still many problems unsolved and many wishes at the customers to make the use more comfortable and efficient at the overall level. If the time of setting up the software package is passed the adoption get more extended and complicated. There is a lot of work at the stage around and the expertise will be required for a long time from now.

IBM Rational Team Concert is a reliable project management solution that suit our day-to-day business processes. It makes it effective to enhance data-centric decisions by visualizing data in real-time.

Well suited area in my team: Our production support team uses it for day to day incident management and problem management. Its built-in features fit the ITIL framework perfectly. Less appropriate area in my team:
We are changing our team structure to DevOps and our software development cycle from a traditional waterfall model to Agile. RTC is not as good as JIRA in Kanban and scrum.

DOORS is a very specific piece of software. It is suited to managing contract/project requirements. It works well to list and connect a lot of data, and then gives you the opportunity to show these relationships in several different ways, both graphical and in reports. The software is costly, so your project needs to be large enough to support it.

If you are using IBM software and more importantly, if you have work with huge process flows (and lots of resources invested on it), DOORS is the way to go. On the other hand, if you have mostly an IT focused agile team or your project is not too big, I can't recommend its use.

Very good tool for requirements management like baselining the requirements, traceability across the lifecyle, coverage matrixes, working on multiple version of requirement at a time, etc. But not up to the mark for requirement development activities like developing interactive wireframes, data modeling, BPMN, or Use case modeling. Also it does not support offline work.

I think that in cases where there is a skilled functional analyst team that is well trained in the use of the tools and completely dismisses the use of Word documents to collect the requirements, it is a good fit. It seems that a good solution to improve efficiency to collect the specification is to use the module. If you need to build more accurate artifacts containing even fields and not just free text this is not possible. It would be helpful to store the specific value in metadata, and it would be interesting to compile artifacts with predefined fields that could be queried.

In my opinion, RTC is probably well-suited for a very large organization that relies on it completely for project management. But it does bring in the overhead of managing and keeping it up-to-date in order to extract its benefits. It is not as good at integrating with other tools/platforms like Git for instance to enable seamless integration between developer check-ins and RTC tasks.

It is more suited to an Agile development methodology. However, it is not a replacement for or crutch to be used instead of a strong, disciplined Agile development staff. The software facilitates your existing process. It would be highly recommended to mature your Agile methodology before software acquisition. The software in a less mature environment, can allow bad habits to impact the Agile methodology discipline.

It is a very good tool for agile scrum project management.

It is most likely well-suited for large organizations. How flexible do your ALM tools need to be? RTC is extremely flexible, but there is an associated learning curve to understand the flexibility. How quickly do we need to put the tools in place? We started with an early version of the tool (2.0), and the process to get RTC operationalized was lengthy.